OpenEdge Development:<br />Progress Dynamics Basic Development Programming with data range security

To show how this works, this section shows you how to use your data range allocation in a specific application object, the Customer SDO generated by the Object Generator. You will retrieve the restriction and apply it to the Customer query before it is opened by the SDO.

Remember that Progress Dynamics generates a separate custom super procedure, called the logic procedure, for each SDO. This procedure lets you customize the behavior of any SDO without modifying the base SDO procedure itself, which remains completely generic. You will edit the logic procedure customerlogcp.p, not the SDO customerfullo.

In the AppBuilder, choose the Open button to open the logic procedure.

The logic procedure appears, with a nonvisual TreeView design window, as shown:

From the AppBuilder toolbar, choose Edit to bring up the Section Editor.

Drop down the section list and select Procedures, then choose New. The New Procedure dialog box appears, as shown:

To change the Customer SDO query before it is ever opened, you will customize the standard ADM initializeObject procedure to make the change before any object initialization takes place.

Note: Because you are editing a separate procedure file from the SDO procedure itself, the AppBuilder’s Section Editor is not able to refer to the list of all overrideable (localizable) procedure names, so you cannot use the Override option to locate the one you want.

Enter the procedure name, then choose OK.

Enter the code shown in Figure 13–2 for the customized version of initializeObject.

Figure 13–2: Example Customer Selection window

Here you are making direct use of the API for the Security Manager. In all of the security functions you have seen so far, the framework code accesses the Security Manager directly for you, so that the supporting behavior for establishing and applying security restrictions is done automatically, without you having to write any 4GL code at all. In this case, however, the framework does not know exactly what use should be made of the range code, so you must do this yourself.

The API for the Security Manager, as well as the API for other Progress Dynamics Managers, is detailed in OpenEdge Development: Progress Dynamics Managers API Reference . The example code makes use of the fact that the handles to the support procedures for the principal Progress Dynamics managers are available as global variables on the client.

The handle to the Security Manager is gshSecurityManager. The internal procedure to run within that handle to get the range security information is rangeSecurityCheck. It takes three input parameters:

The name of the Range Code (‘Country’ in this example).

The name of the object making the request (customerfullo in this case).

The name of an attribute value to check (none in this case).

The From value for the range check.

The To value for the range check.

In this case, the code assumes that the range is limiting access to a particular country, so only the From value is checked. If the value that comes back is blank, then there is no restriction for the current user and the query is not changed. Otherwise, the Country code that comes back is used to qualify the SDO’s query. The code sets the SDO’s OpenQuery property to modify the base query for the SDO.

Once the query has been reset, the procedure executes a RUN SUPER statement to invoke the standard initialization for the SDO, which will include opening the query with its new WHERE clause.

Save and compile the logic procedure. To test it, launch the Customer selection window, custbrowsewin, from the Dynamic Launcher. Remember to check the Destroy ADM Super Procedures box so that the new version of the super procedure customerlogcp.r will be run. You should see the Customer records for the USA only.

This is just one simple example of how you can use the Data Range security structures. Because there is no specific built-in behavior for these records, you can do anything you want with them. For instance, using the Country code example, it might not be appropriate to have a hard-coded country associated with each different user. You can, instead, put some other kind of code into the From and To values. You can even use just a logical flag to indicate “yes, this user is restricted to seeing only data from his or her own country,” and then look up the country in a user table in your own database.

If you look at generalizing the initializeObject code above, you could imagine both the Range Code and Object Name input parameters (and the attribute parameter as well, if you use it) as being variable values passed into the code as input parameters of their own. You could, for example, have a whole set of Data Range or other security structure codes that represented different database fields that require filtering, so that a single procedure run from initializeObject in any SDO in your entire application could apply filtering in a standard way to a number of different fields. The call to this single filtering procedure could then be a hook in a version of initializeObject in a custom super procedure that you define, which could then be made available to every SDO automatically.

Data range conflicts

When a user belongs to more than one security group, and different data range security has been set up against each security group, the framework will not be able to determine which data range security is least restrictive in the context of the application. The framework returns a CHR(3)- delimited list of from values and to values to the calling program. It would then be up to the program to decide which values are least restrictive, and apply them.